In today's Web-oriented enterprise software, a standard programming model uses Uniform Resource Locators (URLs) as a means of resource identification on the Internet and also on intranets. The URL specifications cover resource identification mechanisms, such as HTTP, FTP, MAILTO, etc., known as uniform resource locator (URL) schemas.
In a typical system with a set of resources, each individual resource can be identified by a corresponding URL. Accordingly, the navigation state of the system may be identified by the specific resource being invoked at a specific moment, together with its invocation parameters. Indeed, in the field of Web-enabled applications, the only state the client carries is the navigation state expressed in the form of the URL.
There are two principal navigation states: functional and data. The functional navigation state defines what function (screen) of the application is currently engaged, while the data navigation state defines what data unit (record) of a particular data unit (record) type is being worked on. (See also below, FIG. 7a.)
Traditionally, the client state is a node of the application resource tree. This setup is natively supported by the URL structure, which includes the path to a required node in the resource tree. Such a scheme works perfectly well for applications with isolated, atomic resources. However, for applications that need to expose non-atomic resources, or where exposable resources inter-depend, traditional resource identification becomes an issue.
What is clearly needed is a method and system that allows avoidance of these issues by allowing, from the Application Server point of view, which is the abstract of an application, independent functional and data navigation states. In cases where there are dependencies between the functional and data states (for example, a certain record cannot be shown on a particular screen), such dependencies need to be dealt with on the application level. What is clearly further needed is a method and system for deploying the HTTP URL resource identification technique in a manner that enables the application navigation state to be externalized.
Traditionally, in the web-enabled application world, eXtensible Style Sheet (XSL) transformation is used to facilitate creation of presentations in the form of HTML, based on business data provided in the form of XML, and presentation templates, provided in the form of XSL. For instance, to create a page that displays a list of customers, an XML tag <customers> and its content is translated into HTML tag <table>; XML tag <customer> is translated into HTML tag <tr>, and so on, based on XLS transformation instructions contained in an XSL style sheet. The shortcoming of this approach is that for a different page, displaying a list of orders, the XSL transformation instructions need to be different.
What is clearly further needed is a method and system for a two-phase XSL transformation approach that allows an intermediate step for filling in context-related (for example, customer) data for a specific case, thus simplifying and speeding up the XSL process for situations in which multiple XSL style sheets are employed, such as in customer interaction systems.